home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0128.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  2.0 KB  |  47 lines
  1. On Thu, 1 Jul 1993 11:41:12 +0100 (WET DST), Antonio Franco wrote:
  2. >     I have recently read RFC 1203 (2/91). A question occurred
  3. > me when I saw the following sentence (page 3): "This should allow
  4. > the IMAP protocol to evolve away from its current reliance on RFC822".
  5.  
  6. Please do not believe anything you may read in RFC-1203.  RFC-1203 is NOT part
  7. of any current IMAP development efforts.
  8.  
  9. The base for current IMAP development is RFC-1176.  In spite of it having a
  10. lower number, it is the authoritative document for IMAP.  Extending RFC-1176
  11. is an unpublished document which describes ``IMAP2bis extensions''.  This
  12. document is available from the ftp.cac.washington.edu anonymous FTP server on
  13. the mail/ directory.
  14.  
  15. >     Is there any work being done in order to support other
  16. > message types (for example, X.400 P2(84) or P2(88)) ?
  17.  
  18. There is presently no such work.
  19.  
  20. As Ned Freed suggests, the current thinking is that the way to address this
  21. problem is through X.400 to MIME conversion.  IMAP clients should not have to
  22. deal with multiple message formats and structures.
  23.  
  24. > 1) Fetch
  25. > 1.1) Using the Generic, Canonical and Concrete keys concept.
  26. > 1.2) Using the ENCODING recommended feature.
  27. > 2) Submission
  28. > 2.1) With some extensions to the SEND recommended feature (?).
  29.  
  30. These are RFC-1203 concepts and are not part of IMAP.  Nor will they be:
  31.  
  32.  - The keys concept, although possibly interesting, was not specified to the
  33. point that it could be implemented or even reasonably evaluated.
  34.  
  35.  - The encoding concept is an incorrect understanding of how to do multi-media
  36. and multinational character sets.  It is completely worthless.  The IMAP2bis
  37. extensions solved this problem correctly.
  38.  
  39.  - Sending through IMAP would have a (marginal) benefit only if the IMAP
  40. server is co-located with the client on a local area network.  If the IMAP
  41. server is remote (or in a foreign country), sending through IMAP is
  42. potentially a horribly slow (and expensive!) operation.  It is best not to go
  43. down that slippery slope...
  44.  
  45.  
  46.  
  47.